1. Field of the Invention
This invention generally relates to the communications of compressed video and, more particularly, to a system and method for minimizing jitter in MPEG2 video data communicated via an Internet Protocol (IP) network.
2. Description of the Related Art
The National Television Standards Committee (NTCS)/Phase Alternation by Line (PAL) timing requirements associated with motion pictures expert group (MPEG)2 video communications are very stringent. Fluctuations of the synthesized color sub-carrier cause an impairment of the picture quality. Thus, for a broadcast-level video system, the system frequency requirements might be as tight as +/−3 parts per million (PPM). If a free-running decoder is installed in a personal computer (PC), it may be subject to overflow or underflow, which also damages picture quality.
FIG. 10 is a diagram illustrating the transport of the program clock reference (PCR) used in synchronizing an MPEG systems clock (prior art). The PCR is a timestamp included in a PCR MPEG2 transport stream (TS). The PCR MPEG2TS is typically inserted into the communications stream approximately every 40 milliseconds (ms). However, ISO 13818 only requires insertion every 100 ms.
FIG. 11 is a timing model of an MPEG system, as specified in ISO/IEC 13818-1 (prior art). Although there are variable delays associated with the buffering of the video on both the receive and transmit sides, the constant storage and/or transmission delay permits the overall delay, from Video In to Video Out, to remain constant. Any dithering that occurs in transmission is taken care of in the decoding process. As a result, the PCR jitter can be kept less than 500 nanoseconds (ns). However, when MPEG video is transmitted via an Internet Protocol (IP) network, the storage and transmission delays may vary. There is no requirement that MPEG2 packets be transported per a schedule, and the loading and buffering of IP packets before transmission cannot be predetermined. Route change and variation is another contributor to IP network jitter. As a result, the overall delay, from Video In to Video Out, varies and the system timing requirements cannot always be met.
FIG. 12 is a diagram illustrating the MPEG2TS packet structure (prior art). The PCR timestamp is inserted into a TS header. A MPEG2TS packet, referred to herein as a MPEG2TS, includes TS packets, each made up of a TS header and corresponding TS payload. Note that the PCR is not inserted into every MPEG2TS, as several MPEG2TSs may be communicated in a 100 ms time duration. Using Standard Definition TV (SDTV) as an example, 160 MPEG2TSs typically occur between PCR MPEG2TSs.
FIG. 13 is a diagram illustrating real-time protocol (RTP) as defined by RFC 2250 (prior art). More specifically, a RTP/user datagram protocol (UDP) packet is shown as carried in an IP packet. Conventionally, the RTP packet includes an RTP packet header and a plurality of MPEG2TSs in the RTP payload. The RTP header includes a 32-bit synchronization timestamp, which is referred to herein as a RTP timestamp. Note, the RTP timestamp is not intended for use in recovering the video system target decoder clock. Also note that the RTP timestamp is not associated with any particular MPEG2TS in the RTP payload. Further, the 32-bit RTP timestamp only has a resolution of 90 kilohertz (kHz), insufficient for a 500 ns systems requirement.
It would be advantageous if a means were developed for eliminating, or at least minimizing the MPEG2 systems jitter associated with IP network variable delays.
It would be advantageous if the above-mentioned IP network variable delays could be minimized, by linking a PCR MPEG2TS to a target transmission time.